Introduction

Janelle was excited. She was headed into a 1:1 (“one on one meeting”) with her boss, Kim, for her annual performance review, and Janelle was pretty sure it was going to be a good one. This time last year, at her previous performance review, she’d told Kim she wanted to be a Senior Software Engineer, and Kim’s response had been, “Well, that’s great! Show us that you know how to do what Senior Software Engineers do, and I’m ready to move you up.”

So last year, she’d worked with Marketing to get their website issues sorted out (stupid CSS issues), and then six months ago she’d written a Ruby script to help her team easily push new releases out to one of their few remaining on-premises services. On top of that, over the last four months, she mentored Michael, one of the new hires on the team, and helped him get over the finish line with a few of his stories. Overall, she felt that she was doing some of the very things that she’d seen other Senior Software Engineers at the company doing, so she felt pretty good about this past quarter.

Kimberly was, as always, a few minutes late to the 1:1. “Hi, Janelle. Sorry to be late, but you know how it is.” Janelle nodded, but before she could respond, Kim went on. “Since this 1:1 is a performance check-in, I wanted to open the conversation with telling you that I talked with Dan”—Kim’s manager and thus Janelle’s skip-level manager—“and he and I agreed that your performance this past quarter has been lukewarm. We were really hoping you could show us more than what you’ve been giving us.”

Janelle felt all her enthusiasm just drain down through the floor. Her face must’ve shown that because Kim suddenly smiled a little tiredly. “We still like you, Janelle, we’re not firing you or anything. We just… well, I know you’re really interested in becoming a Senior, and right now you’re just not meeting our expectations for what a Senior does.”

Janelle shook her head. “I don’t understand. I mentored Michael, I worked with Marketing, I wrote the push script… all of these are things that I see Guarav”—one of the Senior Software Engineers on a peer team—“doing all the time.”

Kim sighed. “Yes, but those aren’t actually the things we expect a Senior to be doing. We need Senior Software Engineers to be technical decision-makers, and you didn’t really put yourself forward to be learning the new stuff we’re exploring. We also really need Senior Software Engineers on this team to take a more active role in meeting with the stakeholders of the project, doing presentations and the like. Do you understand now?”

No, Janelle thought, but what difference does it make?

Many, if not most, software developers are intimately familiar with Janelle’s experience. They believe they understand the path to promotion—the things that they are being told (implicitly or explicitly) that they need to do to move up in the ranks—only to find out during performance reviews that that’s not actually what gets people promoted. It’s the same basic problem as “scope creep”: you think you’re aiming at one finish line, only to discover that the finish line is over there. And, by the way, you need to go through these hoops while you’re changing course.

To call it frustrating is an understatement.

Think of it in agile terms. The main reason we go through iterations and sprints is to get frequent customer feedback. Some agile approaches even go so far as to say that we “ship” at the end of every sprint, even the first one. With each sprint, we go through planning to figure out what we will ship so that at the end of the sprint, when we present to the customer what we’ve worked on, the customer can “sign off” on what was built. If customers were to consistently change at the end of the sprint “what they meant” by the stories they were helping to plan at the start… let’s just say that nobody would be surprised if that agile team started looking for other jobs.

And this is exactly what employees do when they’re presented with Janelle’s situation.

The key to avoiding this is the same as with the sprint process: set clear expectations, iterate on them repeatedly, and look for data points (and other evidence) that validate or invalidate the results against the goal(s). In this chapter, we’ll explore what “setting clear expectations” looks like. In particular, we need to try to create expectations that are unambiguous and reasonably objective, while allowing for a certain amount of flexibility.

Great expectations: Ironically, the word “expectations” is a poor choice for what we’re looking for here. Most dictionary definitions of the word have a strong feeling of “anticipation” to them—as in, when one “expects” a thing, there’s good reason to believe it will, in fact, happen. Better words might be “goals” or “targets,” but for whatever reason, the HR community has chosen to use the word “expectations.”